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1.   General 

The  following  two  characteristics  are  commonly  found  in  information  system 
for  the  command  and  control  of  complex,  diversified  military  systems,  for  the 
supply  of  information  input  for  quantitative  analysis  and  managerial  decision 
making,  and  for  the  complementation  of  computer  and  scientist  in  creative 
thinking  ("synnoesis")  [10], 

1)  the  input  and  output  information  flows  from  and  to  a  large,  continuous, 
on-going,  evolutionary  data  base; 

2)  the  algorithms  of  the  process  undergo  permanent  evolution  along  lines 
which  cannot  be  predicted  in  advance. 

Most'  present  day  information  systems  are  designed  along  ideas  proposed  by 
Turing  and  von  Neumann,   The  intent  of  those  authors  was  to  automate  the 
execution  of  procedures,  once  the  procedures  were  completely  determined.  Their 
basic  contributions  were  the  concepts  of  "executable  instructions",  "program" 
and  "stored  program  computer".   Information  systems  based  on  this  conventional 
philosophy  of  computation  handle  effectively  only  an  information  process  which 
1)  is  "self-contained",  in  the  sense  that  its  data  have  a  completely  predeter- 
mined structure,  and  2)  can  be  reduced  to  an  algorithm  in  final"  form,  after 
which  no  changes  can  be  accomodated  but  those  for  which  provision  was  made  in 
advance.   Consequently,  the  current  role  of  automatic  information  systems  in 
defense,  business  and  research  is  mainly  confined  to  simple  routine  functions 
such  as  data  reduction,  accounting , and  lengthy  arithmetic  computations.   Such 
systems  cannot  act  as  evolutionary  extensions  of  human  minds  in  complex,  changing 
environments. 

List -processing  computer  languages  [7]  have  introduced  a  flexible  and 
dynamically- changable  computer  memory  organization.  While  this  feature  permits 
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the  manipulation  of  new  classes  of  data,  it  does  not  solve  the  basic  communica- 
tion problems  of  an  evolutionary  system.   Each  program  must  still  "know"  the 
form  of  its  data;  and  before  any  processing  takes  place,  a  complete  data  set 
containing  a  predetermined  amount  of  data  must  be  supplied. 

Multiple-access,  time-shared,  interactive  computers  [8]  cannot  completely 
make  up  for  the  inadequacies  of  conventional  and  list-processing  systems.   With 
time-sharing,  changes  in  systems  being  developed  can  be  made  only  by  interrupting 
working  programs,  altering  them,  and  then  resuming  computation;  no  evolutionary 
characteristics  are  inherent  in  the  underlying  system  of  a  multiple-access,  time- 
shared  computer.   Thus,  as  preliminary  usage  confirms,  multiple-access  time 
sharing  of  conventional  computers  is  useful  mainly  in  facilitating  debugging  of 
programs,,   While  such  physical  means  for  close  man-computer  interaction  are 
necessary  for  progress  in  information  systems,  they  are  not  sufficient  alone  to 
produce  any  substancial  expansion  in  the  type  of  continuous,  evolutionary, 
automatic  computer  service  with  which  this  paper  is  concerned. 

2o    The  problem 

A  new  basic  philosophy  is  under  development  for  designing  automatic  infor- 
mation systems  to  deal  with  information  processes  taking  place  in  a  changing, 
evolutionary  environment,  [1,5,5]„  This  new  apporach  requires  departing  from 
the  ideas  of  Turing  and  von  Neumann,  Now  the  problem  is  not  "executing  deter- 
mined procedures",  but  rather  "determining  procedures",  Open-endedness  .which 
was  virtually  absent  from  the  Turing-von  Neumann  machine  concept,  must  lie  in 
the  very  foundations  of  the  new  philosophy. 

The  basis  of  the  new  approach  is  an  "incremental  computer"  which,  instead 
of  executing  frozen  commands,  evaluates  expressions  under  the  control  of  the 


available  information  context.   Such  evaluation  mainly  consists  of  replacing 
blanks  (or  unknowns)  with  data,  and  performing  arithmetic  or  relational  reduct- 
ions.  The  key  requirements  for  the  incremental  computer  are: 

1)  The  extent  to  which  an  expression  is  evaluated  is  controlled  by  the 
currently  available  information  context.  The  result  of  the  evaluation  is  a 
new  expression,  open  to  accommodate  new  increments  of  pertinent  information  by 
simply  evaluating  it  again  within  a  new  information  context. 

2)  Algorithms,  data  and  the  operation  of  the  computer  itself  are  all 
represented  by  expressions'  of  the  same  kind.   Since  the  form  of  implementation 
of  an  expression  which  describes  an  evaluation  procedure  is  irrelevant,  decision 
of  hardware  v<; .  software  can  be  made  case  by  case, 

3)  The  common  language  used  in  designing  machines,  writing  programs,  and 
encoding  data  is  directly  understandable  by  untrained  humans. 

While  the  Turing-von  Neumann  computer  is  computation-oriented,  the  incre- 
mental computer  is  interface-oriented.   Its  main  function  is  to  catalyze  the 
open-ended  growth  of  information  structures  along  unpredictable  guidelines.   Its 
main  operation  is  an  incremental  data  assimilation  from  a  variable  environment 
composed  of  information  from  humans  and/or  other  processors.   (Still,  the 
incremental  computer  is  a  universal  Turing  machine,  and  can  perform  arithmetic 
computations  quite  efficiently). 

Current  research  on  the  incremental  computer  is  aimed  at  designing  it  with 
enough  ingenuity  to  make  the  new  principles  as  fruitful  as  the  ones  of  Turing 
and  von  Neumann  (see  [1]  and  [5]).  Some  of  the  main  study  areas  are:  the  design 
of  the  language;  the  class  of  external  recursive  functions  and  a  mechanism  called 
a  discharge  stack  [2]  for  their  fast  evaluation;  the  design  of  a  suitable  memory 
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and  memory  addressing  scheme  (the  latter  problem  is  being  attacked  by  means  of 
higher  order  association  lists);  saving  on  transfers  of  information  in  memory 
and  the  use  of  cyclic  lists;  avoidance  or  repetition  of  identical  strings  with- 
in different  expressions  through  the  use  of  shorthands,  and  related  problems  of 
maintenance  of  free  storage. 

The  following  will  present  a  quite  elementary,  restricted  and  perhaps  in- 
efficient version  of  the  incremental  computer  based  on  LISP.   LISP  is  the 
currently  available  computer  language  which  most  closely  satisfies  the  require- 
ments of  an  incremental  computer  system.   The  purpose  of  this  presentation  is  to 
demonstrate  some  of  the  concepts  of  incremental  data  assimilation  to  scientists 
who  are  familiar  with  LISP.   Features  of  a  preliminary  LISP  implementation  can 
be  used  as  a  guide  in  the  development  of  the  ultimate  language  for  the 
incremental  computer. 

3,    Aspects  of  the  proposed  solution 

Various  structures  have  been  propsed  for  the  language  of  the  incremental 
computer,  mainly  stressing  closeness  to  natural  language  (for  preliminary 
studies  see  [3]  and  [4]),   Here,  however,  we  will  consider  the  case  in  which 
this  language  is  patterned  on  LISP.   In  this  case  a  simplified  version  of  the 
incremental  computer  will  be  represented  by  an  extension  of  the  normal  LISP 
"EVALQUOTE"  operator.   This  operator,  itself  programmed  in  LISP  ,  will  evaluate 
LISP  expressions  in  a  manner  consistent  with  the  principles  of  the  incremental 
computer  which  are  presented  below.   The  LISP  representations  and  programs  for 
implementing  these  principles  will  be  discussed  in  section  U  of  this  paper.   The 
LISP  meta- language  will  be  used  for  all  examples  in  the  following  sections. 
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i)   Omitted  arguments: 

Suppose  func  is  defined  to  be  a  function  of  m  arguments.   Consider  the 
problem  of  evaluating 

func[x2^iX2;  ...;  x^J       (n  <  m)  qs 

Regular  LISP  would  be  unable  to  assign  a  value  to  (1).   However,  for  the  jncre- 
'"ental  computer  (1)  has  a  value  which  is  itself  a  function  of  (m-n)  arguments. 
This  latter  function  is  obtained  from  (1)  by  replacing  the  appropriate  n  argu- 
ments in  the  definition  of  func  by  the  specified  values  xj^,  X2 ,  ...,  x  . 

For  example,  consider  the  function 

list  3  =  ^[[x;y;z];cons[x;cons[y;cons[z;NIL]]]] 
If  A  and  (B,C)  are  somehow  specified  to  correspond  to  the  first  and  third 
arguemnts  in  the  list  3  definition,  then  the  incremental  computer  should  find 
the  value  of  list  3CA;(B,C)]  to  be 

?^[[u];cons[A;cons[u;((B,C))]]] 
ii)   Indefinite  arguments: 

In  regular  LISP  a  function  can  be  meaningfully  evaluated  only  if  each 
supplied  argument  is  of  the  same  kind  —  such  as  S-expression,  functional 
argument,  or  number  —  as  its  corresponding  variable  in  the  definition  of  the 
function.   In  contrast,  the  incremental  computer  permits  any  argument  of  a 
function  to  be  itself  a  function  of  further,  undetermined  arguments.   (If  these 
latter  arguments  were  known,  then  the  inner  function  could  be  evaluated  before 
the  main  function,  as  LISP  normally  does.)  The  value  of  a  function  with  such 
indefinite  arguments  should  be  a  new  function,  all  of  whose  unspecified  arguments 
are  at  the  top  level. 
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For  example,  consider  again  the  function  list  3  defined  above.   In  the 
incremental  computer, 

list  3  [D;A[[u];cons[E;u]];A[[u];carCu]]] 
should  evaluate  to 

(\[Cr;s][cons[D;cons[cons[E;r];cons[car[s];NIL]]]]3 
iii)   Threshold  conditions 

Consider  for  example  the  function  sum  =  C[x;y];x  +  y].  We  say  that  the 
threshold  condition  for  evaluating  a  sum  is  that  both  arguments  of  sum  be 
supplied  and  that  they  both  be  numerical  atoms.   In  general,  a  threshold 
condition  is  a  necessary  and  sufficient  condition  for  completing,  in  some 
sense,  the  evaluation  of  a  function.   In  regular  LISP,  it  is  considered  a 
programming  error  to  request  the  evaluation  of  an  expression  involving  a 
function  whose  threshold  condition  cannot  be  satisfied.   In  the  incremental 
computer,  on  the  other  hand,  expressions  may  be  evaluated  even  though  they 
involve  indefinite  or  omitted  arguments  (as  in  (i)  and  (ii)  above).   In  these 
cases  the  evaluation  is  not  complete  in  the  sense  that  the  values  are  them- 
elves  functions  which  will  require  additional  evaluation  whenever  the  appro- 
priate missing  data  are  supplied. 

Occasionally  the  threshold  condition  for  a  function  does  not  require  the 
presence  of  all  the  arguments.   For  example,  the  threshold  condition  associated 
with  the  logical  function  and  is,  "either  all  arguments  are  present  and  are 
truth-valued  atoms,  or  at  least  one  argument  is  present  and  it  is  the  truth- 
valued  atom  representing  falsity." 
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The  incremental  computer  must  know  the  threshold  conditions  for  carrying 
out  its  various  levels  of  evaluation.   One  of  the  most  challenging  problems  in 
the  theoretical  design  of  the  new  incremental  computer  is  that  of  determining 
efficient  threshold  conditions  for  arbitrary  functions  designed  by  a  programmer. 

The  illustrative  program  described  in  the  next  section  employs  only  the 
most  obvious  threshold  conditions. 

4.   The  program 

Let  us  consider  some  of  the  problems  of  representation  and  organization 
which  must  be  faced  in  the  course  of  implementing  a  LISP  version  of  the 
incremental  computer, 
i)   Omitted  arguments: 

Since  LISP  functions  are  defined  by  means  of  the  lambda-notation  [9],  the 
role  of  an  argument  of  a  function  is  determined  solely  by  its  relative  position 
in  the  list  of  arguments.   If  an  argument  is  omitted,  the  omission  must  not 
change  the  order  number  of  any  of  the  supplied  arguments.   This  can  be  accomplised 
only  if  each  omitted  argument  is  replaced  by  some  kind  of  marker  to  occupy  its 
position.   Therefore  in  this  LISP  formalism  for  the  incremental  computer  each 
function  must  always  be  supplied  the  same  number  of  arguments  as  appear  in  its 
definition;  however,  some  of  these  arguments  may  be  the  special  atomic  symbol 
"NIL''"  which  indicates  that  the  corresponding  argument  is  not  available  for  the 

current  evaluation. 

The  evaluation  of  a  function,  some  of  whose  arguments  are  NIL*'s,  is  approxi- 
mately as  follows:  Each  supplied  argument  (i.e., each  argument  which  is  not_ 
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NIL")  is  evaluated,  the  value  substituted  into  the  appropriate  places  in  the 
definition  of  the  function,  and  the  corresponding  variable  deleted  from  the 
list  of  bound  variables  in  the  definition  of  the  function.   What  remains  is 
just  the  definition  of  a  function  of  the  omitted  variables, 
ii)   Indefinite  arguments: 

An  indefinite  argument,  as  discussed  in  section  3. above,  is  an  argument 
which  is  itself  a  function  of  new  unknown  arguments.   The  present  program 
assumes  that  any  argument  which  is  a  list  whose  first  element  is  the  atom 
"LAMBDA"  is  an  indefinite  argument.   This  convention  does  not  cause  any 
difficulty  in  the  use  of  functional  arguments,  since  they  would  be  prefixed, 
as  S-expressions,  by  the  symbol  "FUNCTION".   However,  there  is  an  ambiguity  be- 
tween indefinite  arguments  and  functional  arguments  in  the  meta- language.   Also, 
it  is  illegal  to  have  an  actual  supplied  argument  be  a  list  starting  with  a 
"LAMBDA",   A  more  sophisticated  version  of  this  program  should  have  some  unique 
way  to  identify  indefinite  arguments  (perhaps  by  consing  a  NIL*  in  front  of 
them) , 

The  treatment  of  indefinite  arguments  is  straightforward  if  one  remembers 
that  a  main  function  and  an  indefinite  argument  are  both  ^-expressions,  each 
consisting  of  a  list  of  variables  and  a  form  containing  those  variables.   The 
process  of  evaluating  a  function  fn  of  an  indefinite  argument  arg  involves,  then, 
identifying  the  variable  v_  in  the  variable-list  of  fn  which  corresponds  to  arg; 
replacing  v  by  the  string  of  variables  in  the  variable-list  of  arg;  and 
substituting  the  entire  form  in  ar£  for  each  occurrence  of  _v  in  the  form  in  fn. 
The  treatment  of  a  conditional  function  containing  an  indefinite  argument  is 
similar  although  somewhat  more  complicated. 
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iii)   Conflicts  of  variables: 

The  same  bound  variables  used  in  different  ^-expressions  which  appear  one 
within  another  'conflict"  in  the  sense  that  they  make  the  meaning  of  the  over- 
all expression  ambiguous.   The  use  of  indefinite  arguments  frequently  leads  to 
such  conflicts.   This  problem  is  avoided  in  the  present  system  by  replacing 
every  bound  variable,  as  soon  as  it  is  encountered,  by  a  brand  new  atomic  symbol 
generated  by  the  LISP  function  gensym. 
iv)   Threshold  conditions: 

Certain  program  simplifications  can  be  made  automatically  by  the  incremental 
computer,  if  corresponding  threshold  conditions  are  satisfied.   In  particular, 
if  every  argument  of  a  function  is  the  sytnbol  NIL",  then  the  function  of  those 
arguments  is  replaced  by  the  function  itself. 

The  incremental  computer  is  represented  by  the  LISP  function  evalquote  1. 
This  function  is  similar  to  the  normal  evalquote  operator  except  that 
evalquote  1  first  checks  to  see  if  any  incremental  data  processing,  of  the 
kinds  discussed  above,  is  called  for.   If  so,  evalquote  1  performs  the 
appropriate  partial"  evaluations.   If  the  given  input  is  a  normal  LISP  function 
of  specified  arguments,  on  the  other  hand,  the  effects  of  evalquote  1  and 

evalquote  are  identical. 

Appendix  I  is  a  listing  of  the  complete  deck  for  a  test  run,  and  includes 
the  definitions  of  evalquote  1  and  all  its  subsidiary  functions.   The  results  of 
the  run,  showing  examples  of  incremental  data  assimilation  with  the  subst. 1 
function  (which  is  identical  to  the  normal  LISP  subst  function),  are  given  in 
Appendix  II.   The  curious  reader  can  understand  the  detailed  operation  of  the 
programs  by  studying  these  listings. 
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5.   Conclusions 

We  can  now  make  the  following  observations  concerning  the  use  of  LISP  as 
the  language  for  the  incremental  computer: 

i)   Although  perhaps  too  inefficient  to  be  a  final  solution,  LISP  is  still  a 
very  useful  language  with  which  to  illustrate  the  features  of  a  new  concept  of 
algorithm  representation.   It  is  especially  easy  to  use  LISP  to  design  an 
interpreter  for  a  language  similar  to,  but  different  in  significant  ways  from, 
LISP  itself. 

ii)   The  program  described  in  this  paper  is  quite  limited  with  regard  to  its 
implementation  of  both  LISP  and  the  incremental  computer.   If  a  more  complete 
experimental  system  were  desired,  the  present  system  could  easily  be  extended 
in  any  of  several  directions.   For  example,  in  LISP,  allowance  could  be  made 
for  the  use  of  functions  defined  by  machine-language  subroutines,  and  the  use 
of  special  forms;  in  the  incremental  computer,  threshold  conditions  could  be 
inserted  to  allow  partial  evaluation  and  simplification  of  conditional 
expressions. 

iii)   Replacing  all  bound  variables  by  new  symbols  is  too  brutal  a  solution  to 
the  "conflict"  problem;  the  resulting  expressions  become  quite  unreadable. 
Bound  variables  frequently  have  mnemonic  significance,  and  therefore  should  not 
be  changed  unless  absolutely  necessary.   A  more  sophisticated  program  would 
identify  those  symbols  which  actually  caused  a  conflict,  and  then  perhaps  replace 
each  offending  symbol  with  one  whose  spelling  is  different  but  similar. 
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iv)   When  a  function  of  an  indefinite  argument  is  evaluated,  the  form  in  the 
argument  is  substituted  for  each  occurrence  of  a  variable  in  the  form  in  the 
function  definition.   Similarly,  when  a  function  has  omitted  arguments,  those 
arguments  which  were  not  omitted  are  each  evaluated  and  substituted  for  each 
occurrence  of  variables  in  the  form  in  the  function  definition.   In  the 
interest  of  saving  computer  space,  we  must  be  sure  that  what  is  substituted  is 
a  reference  to  an  expression,  not  a  copy  of  the  expression.   In  the  interest  of 
readability,  perhaps  the  print-outs  should  similarly  contain  references  to 
repeated  sub-expressions,  e.g.  in  the  form  of  ^^-expressions,  rather  than 
fully  expanded  expressions. 
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TEST  B    RAPHAEL         M948  APPENDIX  I:      Progrim  Listing 

DEFINE  ((  __  _ 

(EVALQUOTEl   (LAMBDA   (FN   X)  "       '  '" 

.(_A  P  P  L  Y  1_  _FN__X N  ID  )  J_ 


(APPLYl   (LAMBDA   (FN   X   A)   (COND' 
_JJATOM   FN)   (COND  


((GET   FN   (QUOTE   EXPR))   (APPLYl   (GET   FN   (QUOTE  EXPR ) )  X  A)) 

_,((EQ   FN (QUOTE  ._CAR)  )   (COND        

■   ((NULL*   (CAR   X))   (QUOTE   CAR))      "       ^'    ■ 

(.  (LAM  1 LCLA.R X))        (APP  2  _   X       ( QUOJIE CAR)  )  ) 

(T   (CAAR   X)  )   )  ) 

L(EQ   FN  _  (QUOTE   CDR)  )   (COND 

((NULL*   (CAR   X))   (QUOTE   CDR)) 

(  (LAMl  .  (CAR  _  __XX)_.^JAPP2  X  (QUOTE   CDR))) 

(T   (CDAR   X))   )) 

L(_EQ FN (^.UP_TE__CON_S_L)_(  COND  (  (  LAM2  X  )  (  APP3  X  A (QUOTE  CONS)  Ll_ 

(T   (CONS   (CAR   X)   (CADR   X) ) )   ) ) 
_JJEQ   FN_  (QUOTE  _  ATOM))   (COND   ((NULL*   (CAR   X)) (QUOTE  ATOM)) 
{(LAMl  (CAR  X))  (APP2  X  (QUOTE  ATOM)))  (T  (ATOM  (CAR  X)))  )) 

( (EQ   FN   (QUOTE   EQ))  (COND  ( ( LAM2  X)(APP3  X  A  (QUOTE   EQ ) ) )    

(T   (EQ  (CAR   X)  (CADR  X) ) )   ) ) 
(T   (ERROR  (LIST   (QUOTE   APPLYl)   FN   X   A)      )  )   )  ) 


((EQ  (CAR   FN)    (QUOTE   LAMBDA))  (APPLY2  (LAMS 

(CONS (QUOTE   LAMBDA)   (UNFLICT   (CDR   FN)))    X)   A)) 

(T   (ERROR   (LIST   (QUOTE   APPLYl)   FN   X   A ) ) )   ))   ) 
(LAMl   (LAMBDA   (X) 


(AND   (NOT  (ATOM   X))   ( EQ  (CAR   X)   (QUOTE   LAMBDA)))   )) 


(APP2   (LAMBDA   (X   A) 
(LIST   (CAAR   X).   (CADAR   X)   (LIST   A   (CADDAR   X))   )) 


(NULL*^   (LAMBDA   (X)   (  EQ  _X  _  (QUOTE   NIL*))   )) 

(LAM2   (LAMBDA   (X)   (OR 
(MEMBER  (QUOTE  NIL*)   X)   (LAMl  (CAR  X)  )   (LAMl  (CAPR  X) )  ) ) ) 


(APP3   (LAMBDA  (X  A  F)  ((LAMBDA   (U   V)   (APPLYl . 

(LIST  (QUOTE  LAMBDA)  (LjST  U  V)(LIST   F   U   V))   X   A)) 
(GENSYM)    (GENSYM)  )  )  ) „ 

(LAMS   (LAMBDA  _(  FN XJ__J_PROG jJ/AR.l^ARGl  VARS  ARGS  ARG2  M LJL 

(SETQ   M   (CADDR   FN) ) 

_  (SETQ   ARGS   X)    _  .  ; . 

(SETQ   VARS   (CADR   FN) ) 

LOOP   (SETQ   L   (CAR   ARGS)) 

(COND   ((LAMl   L) 

_(G0   FLICT)  )  )       _  

(SETQ   VARl   (CONS   (CAR   VARS)   VARD) 

(SETQ   ARGl   (CONS   L   ARGl))  ..  ^  ..   

LOOPl   (SETQ   VARS   (CDR   VARS)) 

(COND   ((NULL   VARS)  (RETURN   (LIST   (REVERSE   VARl)   M 

(REVERSE   ARGl ) ) ) ) ) 

(_SET_Q   ARGS (_CDR ^ARGS  )  ) 

(GO   LOOP) 

FLICT   (SETQ   L   (UNFLICT   (CDR   L)    ))       

(SETQ   ARG2   (CAR   D  ) 

L00P2   (SETQ   VARl   (CONS   (CAR   ARG2  )   VARl))  ___     

(SETQ   ARGl   (CONS   (QUOTE   NIL*)   ARGl)) 

(SETQ   ARG2   (CDR   ARG2)) ....      

(COND    (ARG2   (GO   L00P2 ) ) ) 

(SETQ   M   (SUBST   (CADR   L)   (CAR   VARS)   M))         

(GO   LOOPl )    ) ) ) 


(UNFLICT   (LAMBDA  (Y    )   (PROG   (L    ) 
_{SETO   L   (CAR   Y)l 


LOOP   (COND   ((NULL   L)   (RETURN   Y))) 

(.S  E  T  Q  __Y.  __XSU  BSI (GENSYM)   (CAR   L)   YH 

(SETQ   L   (CDR   D) 
(G0_  LOOP)  _  )  )  ) 


iAPPLY2   (LAMBDA  (L   A)   (COND   ((MEMBER   (QUOTE   N I L* )   ( CADDR   L ) ) 

(APPLY3   LA))   (T   (EVALl   (CADR   L)   (PAIRLIS  (CAR  L) 
(CADDR   L)   A)))   ))) 


J.APPLY3_(  LAMBDA (L A) (SEARCH   (CJ\DDR   L) 

(FUNCTION   (LAMBDA   (J)   (NOT   ( EQ   (CAR   J)   (QUOTE   NIL*)))   )) 
(FUNCTION (LAMBDA   (J)   (APPLY4   LA))) 

(FUNCTION   (LAMBDA   (J)  (LIST  (QUOTE  LAMBDA)(CAR  L)(CADR  L))))  )  )  )" 


(APPLY4   (LAMBDA   (L   A)   (PROG   (VARS  FORM  ARGS  M  ARGl) 

(SETQ   VARS   (CAR__L)_) 

(SETQ   FORM   (CADR   D) 
(SETQ   ARGS   (CADDR   D) 


LOOP   (SETQ   ARGl   (CAR   ARGS)) 

(COND   ((EQ   ARGl   (QUOTE   NIL*))   (GO   B))   ) 


(SETQ   FORM   (SUBST  (LIST  (QUOTE   QUOTE)   ARGl)   (CAR   VARS)  FORM)) 
^LOOPl   (SETQ   ARGS  _(CDR   ARGSjJ 

(COND  ((NULL  ARGS) (RETURN        (LIST  (QUOTE  LAMBDA)  M  FORM)    ))) 
(SETQ   VARS   (CDR   VAR  S  ) .) 

(GO   LOOP) 
B  (SETQ  _  M   (CONS   (CAR   VARS)   M)) 

(GO   LOOPl)   ))) 


(EVALl   (LAMBDA  (E   A)  (COND   ((ATOM   E)   (COND 
JJGET   E   (QUOTE   APVAL))   (EVAL   E   A)) 


((EQ   E   (QUOTE  NIL*))  (QUOTE  NIL*))(T  (CDR  (ASSOC  E   A))  )  )) 

_L(ATOM  (CAR  E))    (COND 

((EQ   (CAR   E)    (QUOTE   QUOTE))   (CADR   E)) 

((EQ        (CAR       E) (QUOTE       COND))      J  EVCONl ^(CDR       E)       A)) 

((EQ        (CAR       E)        (QUOTE       LAMBDA))       E) 

(T   (APPLYl   (CAR   E)__  (EVLISl   (CDR   E)   A)  A))   )    _L 

(T     (APPLYl   (CAR   E)   (EVLISl   (CDR   E)   A)  A))   )  )) 


(EVCONl   (LAMBDA   (C   A)    ((LAMBDA   (X)   (COND 
_  ((LAMl   X)    (LIST^  (CAR   X)   (CADR   X )_ 


(CONS  (QUOTE  COND)(CONS  (LIST  (CADDR  X)(CADAR  O)  (CDR  C)))  )  ) 

((EVALl   X   A)    (EVALl ^  (CADAR  C)   A))    

(T   (EVCONl   (CDR   O   A))  >)   (CAAR   O)   )) 


(PAIRLIS   (LAMBDA   (X   Y   A)   (COND   ((NULL   X)   A) 

(T   (CONS  (CONS  .(.CAR  _X)  (CAR  Y)  )  (PAIRLIS  (CDR  X)(CDR  Y)  A))  ))  ))   _ 

(ASSOC   (LAMBDA   (X   A)   (COND   ((EQUAL  (  CAAR  A )  X )  ..  ( CAR   A )  )  .  . 
(T   (ASSOC   X   (CDR   A)))   ))) 


(EVLIS'I   (LAMBDA   (M   A)   (COND   ((NULL   M)   NIL) 

(_T  .  (CONS  _J  EVALl (CAR^M)   A)   (EVLISl   (  CDR_  M  )^  _A  )  )  )   >)) 

(   SUBSTl   (LAMBDA   (  X  _Y_  Z  ).  .  (  COND  _(  (  AJOM  ..  ZJ^...  (  COND 

(JL*JjJo.(iJiu3sii_J<_jr__LCAR_Z,L) (_SUBS^-a_X_J^ LCDB__I1-L1JJ-11- 


)  ) 

EVALQUOTEl 


(SUBSTl   {(A   B)   C   NIL*)    ) 
'ALQUOTEl 

(SUBSTl   ((LAMBDA   (X)   (CONS   X   (QUOTE   ( B )  )  )")   C   (C   Y   ("c"  D )  )  )  T 
'ALO  up  T_Ea 

(SUBSTl   (NIL»   NIL»         NIL*) ) 
'ALQUOTEl       _ 

(SUBSTl   (ONION   NIL*   (LAMBDA   ( X  Yf"  ( CONS   X   Y )  ) "  )] 
'ALQUOTEl 

(SUBSTl   ( (A  .  B)   C   (C   Y   (C   D) )   )  ) 
STOP  )))))))))) 


FIN 


FUNCTION    EVALOUOTE    HAS  BEEN  ENTERED,  ARGUMENTS. 

._EVALQUOtEl 

(SU6ST1  ( (A  B)  C  NIL*)) 


END  OF  EVALQUOTE,  VALUE  IS  .._   .  

(LAMBDA  (G00003)  (CONO  ((ATOM  G00003)  (COND  ((EQ  G00003  (QUOTE  O)  (QUOTE 
_LQUQT£_  J  A  Bi  J  ( QUOTE_CJ  _(CAR_G00003  )J  _  (  SUBSTX.J  QUOTE  _l A  B) )  .( QUOTE _C)..  ( C  C 


FUNCTION    EVALQUOTE    HAS  BEEN  ENTERED,  ARGUMENTS. .  

6VALQU0TE1 

(SUBSTl  ((LAMBDA  (X)  (CONS  X  I  QUOTE  (B)  I)  J  C  (C^T-  (C- D) )  ) ) 


END  OF  EVALQUOTE,  VALUE  IS  .. 

(LAMBDA  .{GQ0007)  (COND  ((ATOM  IQUOTE_a(L_Y_^lC_  D) )  i )  (COND  ((EQ  (QUOTE  (C  ' 
QUOTE  (8))))  (T  (QUOTE  (C  Y  (C  D))))))  (T  (CONS  (SUBSTl  (CONS  G00007  (QUI 
Y_(C  DJ  J  U)_l  SUBSTl  ICONS  G00007_lQUOTE..lBJJi_IQUOTE_Ci-tCOR- 1  QUOTE  (CY. 


_F.UNCT10N. EVALQUOTE,  _. HAS  _BEEN  ENTERED, -ARGUMENTS. 

EVALQUOTEl 

(SUBSTl,  (NIL*  NIL»  NIL*).) 


END  OF  EVALQUOTE,  VALUE  IS  ..  ^^ 

JJ.AMBDA_tG00008  G000C9  GOOOlO)  ^COND^J  ( ATOM  GOOOlO)  (COND  ((EQ  GOOOlO  GO 
(SUBSTl  GOOOOB  G00009  (CAR  GOOOlO))  (SUBSTl  G00008  G00009  (COR  GOOOlO))) 


FUNCTION    EVALQUOTE    HAS  BEEN  ENTERED,  ARGUMENTS.. 
EVALQUOTEl 
(SUBSTl  (ONION  NIL*  (LAMBDA  (X  Y)  (CONS  X  Y)))) 


f::SM^^A^yS^S^?^^G00^Sli;%i00l2,  (COND  ((ATOM  'CONS  GOOOl.  000013).  (CCSO 
QUOTE  ONION))  (T  (CONS  GOOOK.  G00015))))  (T  <tONS(SUflST  QUOTE  ONICN) 
(SUBSTl  (QUOTE  ONION)  G00012  (CDR  (CONS  GOOOU  GOOD  1 5 )))))) ) 


ARGUMENTS.. 


APPENDIX-Ili-.  Result  of  computer  ruu- 


)ND  (  (EQ  G00003 
JBSTl  (QUOTE  (A 


(QUOTE  O) 
Bi)  (QUOTE 


(QUOTE  (A  B)) )  (T  G00003))) 
C)  (CDR  G00003)) J)JJ__„_ 


(T  (CONS  (SUBSTl 


-^ARGUMENTS.. 

)  C  (C  Y  (C  D))  )} 


IC  D))n  tCONO  ((EQ  (QUOTE  (C  Y  (C  D)  )  )     (QUOTE  O)  (CONS  G00007  ( 
(CONS  (SUBSTl  (CONS  G00007  (QUOTE  (6)))  (QUOTE  C)  (CAR  (QUOTE  (C 
BJ}J  (QUOTE  CJ  (CDR  (QUOTE  (C  Y  (C  D)J)))Jni  


ARGUMENTS.. 


DM  GOOOlO)  (COND 
Tl  G00008  G00009 


( (EQ  GOOOlO  G00009) 
(COR  GOOOlO)) )  ))) 


G00008)  (T  GOOOlO)))  (T  (CONS 


ARGUMENTS.  . 
Y)  ))  ) 


DM  (CO\S  GOOOlO  G00015))  (COND  ((EQ  (CONS  GOOOlO  ^°°°^^ LnSn?i?  , 
(T  (CONS  (SUBSTl  (QUOTE  ONION)  G00012  (CAR  (CONS  G00014  G00015))) 
DOOl^  G00015) )))))) 


FUNCTION         eVALQUOTe         HAS    BEEN    ENTERED.  Var.iMPkiTc 
VALOUQTEl  ci^iCKCUf    ARGUMENTS., 


EVALQUOTEl  

(SU8ST1     ((A    B)    C     CC    vTc    0)))) 
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